Terminal-tab Resume silently extends sandbox TTL to 30 minutes

What the bug is

SandboxInspectNotFound is rendered on both the filesystem and terminal tabs for paused sandboxes and renders the unconditional message:

// inspect/not-found.tsx
<>
  Resume this sandbox to access the {resourceName}.
  <span className="mt-1 block text-fg-tertiary">
    Runs for {RESUME_TIMEOUT_SECONDS}s, then stops unless the timeout is
    extended. You can pause it again anytime.
  </span>
</>

where RESUME_TIMEOUT_SECONDS = Math.round(SANDBOX_RESUME_TIMEOUT_MS / 1000) = 70. So the user is told the resumed sandbox will run for 70 seconds.

On the filesystem tab this promise is honest: resumeSandbox() in inspect/context.tsx calls trpcClient.sandbox.resume.mutate(...), whose server mutation does Sandbox.connect(... timeoutMs: SANDBOX_RESUME_TIMEOUT_MS /* 70_000 */).

On the terminal tab, the same Resume button takes a completely different path that ignores SANDBOX_RESUME_TIMEOUT_MS entirely.

Code path that triggers it

Step-by-step trace from src/features/dashboard/sandbox/terminal/view.tsx:

1. Sandbox is paused → SandboxInspectNotFound is shown with the "Runs for 70s" copy.
2. User clicks Resume sandbox → onResumeSandbox runs setShouldResumeSandbox(true).
3. With shouldResumeSandbox=true, the empty-state branch at lines 67–80 is bypassed and DashboardTerminal is mounted at lines 84–101 with autoStart, launchTarget={sandboxId, template}, and sandboxConnectRequestTimeoutMs={SANDBOX_TERMINAL_RESUME_TIMEOUT_MS} (= 70_000).
4. autoStart triggers queueTerminalCommand → startTerminal → openTerminalSandbox → acquireTerminalSandbox → trpcClient.sandbox.openTerminal.mutate({ teamSlug, template, sandboxId, requestTimeoutMs: 70_000 }).
5. The openTerminal mutation in src/core/server/api/routers/sandbox.ts hits the if (sandboxId) branch:

const sandbox = await Sandbox.connect(sandboxId, {
  ...connectionOpts,
  timeoutMs: TERMINAL_SANDBOX_TIMEOUT_MS, // 30 * 60 * 1000
  requestTimeoutMs,                       // 70_000 — HTTP timeout only
})

Sandbox.connect's timeoutMs is the SDK's sandbox-TTL parameter — exactly the field the inspect-side comment in constants.ts warns about. requestTimeoutMs is only the HTTP-call timeout, not the sandbox lifetime. So clicking Resume from the terminal tab grants the sandbox a 30-minute TTL.

Why existing code doesn't prevent it

The PR added SANDBOX_RESUME_TIMEOUT_MS and the sandbox.resume mutation specifically to avoid this, with an explicit comment:

Kept short on purpose: resuming for inspect should give a brief debug window, not silently extend a customer sandbox's lifetime.

The filesystem path in inspect/context.tsx calls sandbox.resume. But the terminal tab's Resume button never reaches sandbox.resume — instead it mounts DashboardTerminal, which only knows how to call sandbox.openTerminal, and that mutation hard-codes TERMINAL_SANDBOX_TIMEOUT_MS. There is no resume-aware code path on the terminal side.

Impact

A customer sandbox that was paused (possibly by the new Pause button itself) can be silently revived for 30 minutes of billable lifetime every time a developer opens its terminal tab and clicks the Resume button — while the UI on the very same screen tells them it will run for 70 seconds. This is a 26× discrepancy between the displayed lifetime and the actual lifetime, on the exact action the PR description claims has been hardened against this behaviour.

Step-by-step proof

1. Open a sandbox-details page for a paused sandbox at /dashboard/{teamSlug}/sandboxes/{sandboxId}/terminal.
2. The terminal tab renders SandboxInspectNotFound → message: "Resume this sandbox to access the terminal. Runs for 70s, then stops unless the timeout is extended."
3. Click Resume sandbox.
4. setShouldResumeSandbox(true) causes DashboardTerminal to mount with launchTarget={sandboxId, template} and sandboxConnectRequestTimeoutMs=70_000.
5. DashboardTerminal auto-starts → openTerminalSandbox(... sandboxId, requestTimeoutMs: 70_000 ...) → trpcClient.sandbox.openTerminal.mutate({ ..., sandboxId, requestTimeoutMs: 70_000 }).
6. Server-side: Sandbox.connect(sandboxId, { ..., timeoutMs: 30 * 60 * 1000, requestTimeoutMs: 70_000 }) — sandbox is resumed with a 30-minute TTL.
7. UI promise vs. reality: shown 70s, actual 1800s.

How to fix

Two viable options:

1. Two-step on the client (preferred — matches filesystem flow): In SandboxTerminalView, when the user clicks Resume, call trpcClient.sandbox.resume.mutate({ sandboxId, requestTimeoutMs: SANDBOX_RESUME_TIMEOUT_MS }) first, then mount DashboardTerminal (which now just attaches a PTY to an already-running sandbox).

2. Resume-aware openTerminal: Add a mode: 'resume' | 'attach' (or boolean) input to the sandbox.openTerminal mutation; in resume mode pass timeoutMs: SANDBOX_RESUME_TIMEOUT_MS to Sandbox.connect instead of TERMINAL_SANDBOX_TIMEOUT_MS, and have DashboardTerminal plumb the resume flag from SandboxTerminalView.

Option 1 keeps sandbox.resume as the single source of truth for the resume-TTL invariant and makes the terminal-tab flow structurally identical to the filesystem-tab flow.